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BUSINESS RULES AUTOMATION IN DATABASE APPLICATION 
DEVELOPMENT AND MAINTENANCE 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

5 The present invention relates to database application development. 

2. Stateof the Art 

Database application software is layered on top of database software 
provided by such vendors as Oracle, Sybase, Informix, etc. The database 
application software enables the underlying database software to be used by 

10 non-experts to perform everyday business tasks, e.g., order entry, invoicing, 
collections, etc. Database application development is typically an arduous, 
time-consuming process performed by skilled computer programmers, and 
database application maintenance is often more arduous still. 

Software tools have been developed to automate (to a greater or lesser 

IS degree) various aspects of database application development, including data 
defmition and user interface defmition. Data definition involves describing the 
structure of information in a database. A Data Definition Language (DDL) is a 
specialized language used to create new databases and specify the logical structure 
of the data (i.e., the database schema). One notation for representing database 

20 schemas is the "entity-relationship" (E/R) model, which is graphical in nature and 
uses boxes and arrows to represent the essential data elements and their 
relationships. 

For data definition, CASE (Computer Aided Software Engineering) tools 
are available that generate one or more DDL files from E/R diagrams. For user 
25 interface definition, so-called **4GL** and "screen painter" products are available 
that automate the bindmg of tables to user interface screens with basic services for 
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both retrieval and update. These activities, however, represent only a fraction of 
the work involved in database application development. 

Much (or even most) of the work involved in database application 
development relates to business rules. Business rules automate data manipulation. 

5 An example of a business rule is "the customer balance is the sum of the unpaid 
orders" Typically, business rules are implemented using triggers and stored 
procedures. A stored procedure is a callable program that is declared as an object 
within a database schema. A trigger is a stored procedure invoked in response to 
an insert, update or delete SQL (Structured Query Language) statement. Triggers 

10 and stored procedures are manually coded by skilled progranraiers. Such codrng, 
can be a painstaking, error-prone process. 

Alternatively, such logic can be added into Applications Servers, for 
example as EJB (Enterprise JavaBeans) objects. This provides various advantages 
and scalability (one can provide multiple application servers to balance the load), 

15 or integration (since the data is no longer restricted to SQL). However, the 
underlying problem remains: coding an EJB is just as hard/time-consuming as 
coding a trigger. Both suffer from a single underlying root cause: reliance on 
procedural programming languages to enforce business logic. 

Furthermore, business rules can and should evolve with the business. 

20 Changing business rules calls for code rework, also a painstaking, error-prone 

process. The distinct possibility (or probability) is that in a fast-changing business 
environment, without the expenditure of exorbitant amount of resources, 
information technology will be unable to keep up with the business. 

What is needed, dien, is a database application development tool that allows 

2S business rules to be specified in manner that is readily understood and that 

automatically builds or constructs code to implement and enforce those business 
rules. 
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SUMMARY OF THE INVENTION 
The present invention, generally speaking, provides a data application 
development method for allowing a user to specify business rules (data 
requirements pertaining to one or more business functions) and for automatically 
S generating code that enforces those business rules. As in a spreadsheet, rules may 
be readily specified and modified without concern for interactions between various 
rules. A business rules compiler performs rule/transaction mapping, rules 
ordering, rules optimization, and rules targeting to automatically generate code 
that enforces the business rules. 



10 BRIEF DESCRIPTION OF THE DRAWING 

The present invention may be further understood from the following 

description m conjunction with the appended drawing. In the drawing: 

Figure 1 is a diagram illustrating the process of developing a database 
application in accordance with two-tier deployment; 

15 Figure 2 is a diagram illustrating the process of developing a database 

application in accordance with three-tier deployment; 

Figure 3 is a screen display of a Business Rules Designer, including a 
Derivation tab; 

Figure 4 is a screen display of a Constraints tab of the Business Rules 
20 Designer; 

Figure 5 is a screen display of a Relationships tab of the Business Rules 
Designer; 

Figure 6 is a screen display of an Events tab of the Business Rules 
Designer; 

25 Figure 7 is a screen display of a Rules Builder; 

Figure 8 is a partial E/R diagram useful in illustrating rule chaining; and 
Figure 9 is a block diagram of a Busmess Rules Compiler. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
In the following description, the overall database application development 
environment will be described, followed by the manner in which business rules are 
specified in accordance with an exemplary embodiment of the invention. The 
5 manner in which business rules are compiled will then be described. 

Development Environment 

An overview of the development process using the present development 
tool is shown in Figure 1. Referring to Figure 1, a design-time environment is 
shown on the left-hand side of the figure, and a run-time environment is shown on 

10 the right-hand side of the figure. In order to generate a multi-form application to 
run against a database server 100, a local database, or repository 110, is created. 
Within the repository, a data model 111 of the server database is created. To this 
data model is added additional ""layers'" of information, including business rules 
113 (described in detail hereafter) and application defmition information 115. The 

15 application definition information 1 15 may be captured as the user draws the 
application within an application drawing area 120 (displayed on a computer 
screen, not shown) using drag-and-drop techniques as described more ftiUy in U.S. 
Application Serial No. 08/630,020 entifled AUTOMATED CLIENT/SERVER 
DEVELOPMENT TOOL USING DRAG-AND-DROP METAPHOR, filed April 

20 9, 1996, incorporated herein by reference. 

The application defmition information 115 may itself be in the logical form 
of a database. In a preferred embodiment, an application is described as a 
collection of table rows related in one-to-many fashion. An application describes a 
multi-form program and is represented by a table row within a table JadeApps 

25 1 16. ("jade" stands for "Java Application Development Environment.") A 
database may contain several applications, each of which is represented by an 
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application drawing (120). An application may contain many forms, each of which 
is described by a single row within a table JadeAppForms 117. A form may 
contain multiple tables, each of which is described by a table row within a table 
JadeAppFormTbls 118. Finally, each table may respond to user input to cause a 
5 transition to another form. Each transition is described by a table row within a 
table JadeAppFormShows 119. 

The present development tool may be built upon and leverage the 
capabilities of existing popular software packages. In an exemplary embodiment. 
Microsoft Access is used as the repository. Microsoft Access is a relational 

10 database management system that is part of the Microsoft Office Pro application 
suite. Of course, other database management systems and other target 4GL 
programming languages may be used. 

Generated applications can take a number of organizations. In a "code 
generation" approach, an application contains two types of code: form-specific 

15 code and generic code. Code that pertains to a particular form is form-specific 
code. Other code (stored as "modules") is more general m nature. In the case of 
the present tool, this includes, for example generic code that, when a row becomes 
current, synchronizes each Dependent Recordsource (i.e., opens Dependent 
Recordsources using parameter values from the source Recordsource). Referring 

20 still to Figure 1, the generic code constitutes a run-time library 130 (Vision 

Foundation Classes, or VFC) that is "included" as part of the final application. 

Or, generated applications can be a set of classes, one for each form. Each 
such form class includes a set of objects corresponding to both graphical objects 
(text boxes, grids and so forth) and semantic objects that provide behavior to 

25 retrieve/update data, perform form transitions, or pick foreign key values. The set 
of objects in conjunction with their property settings (set in the Design 
Environment) provide the desired behavior. In the present system (Vision Jade), 
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this behavior is inherited from a set of VFC classes (of which objects are 
instances) that operate (per property settings) to provide the designated behavior. 
Both organizational approaches are, for this purpose, equivalent. 
The database code generator creates data objects within the server database 
5 based on information stored in the data model using, for example, DDL (Data 
Description Language). In addition, in the case of a two-tier implementation, the 
database generation code generates trigger code that enforces the business rules 
specified in the repository. Because no manual codmg is required, either on the 
client side or the server side, the application can be easily modified, repeatedly if 

10 necessary, and regenerated. The "coding waterfall" problem characteristic of the 
prior art is thus avoided. 

Referring to Figure 3, in the case of a three-tier implementation, the 
process is similar. However, instead of the client application interacting directly 
with the database, an additional server tier, the "business logic server," is 

1 5 introduced. The business logic server includes business objects-classes that 

enforce busmess rules-and application server code. The application server code 
performs such task as load balancing, fail over, conununications polling, and 
physical read/write transactions with the database. The database stores data 
objects-the physical data itself. Data represented by data objects (also be referred 

20 to as base components) physically reside on disk. Also of interest are query 

objects-SQL constructs that allow the user to, from the point of view of the user, 
define combination data objects, e.g., joins/projections of data objects. Query 
objects allow for the realization of "virtual" business objects. Data objects and 
query objects are subclasses of business objects within the object model hierarchy 

25 followed by one embodiment of the invention. 

Business logic server code is generated by a business logic server code 
generator based on the business rules specified in the repository. These may, for 
example, operate as Corba or EJB objects, or some equivalent distributed object 
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protocol. The database code generator no longer generates trigger code as in the 
two-tier model. 

In general, the present invention is applicable to an "N-tier" architecture. 
The business logic server may, for example, interface to a separate Web server. 
More than one business logic server may be provided for scalability reasons. 
Multiple business logic servers may be provided, each one implementing a 
particular business function, e.g., payroll, inventory, etc. 

Business Rules— Specification 

Declarative rules provide a simple mechanism to enforce business 
requirements across business functions. A business ftinction is an action performed 
by the user of an application to fulfill a specific business purpose, for example, die 
entry of a new order. A business requirement is a statement for objectives for part 
of a business function that identifies the objectives for working with data. A 
requirement usually encompasses a series of validations and computations that 
begin as an update on a data object and may in mrn affect other data objects. For 
example, the entry of each order item in a new order could mclude the 
requirement diat the cost of the order item must not cause the customer balance to 
exceed the customer's credit limit. 

The functionality of declarative business rules is comparable to spreadsheet 
functionality as seen in Table 1. 
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Table 1 



Spreadsheet functionality 



The formula to determine a 
spreadsheet cell value may refer to 
many other spreadsheet cell values, 
each determined by its own formula 



Declarative business rule functionality 



The rule to determine a column value 
may refer to many other colunm 
values, each determined by its own 
rule. 



10 



15 



A change to the value or the formula 
for a spreadsheet cell, or the insertion 
or deletion of spreadsheet rows, may 
cause automatic changes to many other 
cell values that refer to the changed 
cell value in their own formulas. 



A change to the value or rule for a 
colunm, or insertion or deletion of 
records, may cause automatic change 
to many other coliunn values that refer 
to the changed column value in their 
own rules. Each declarative business 
rule is defined in a single data object. 
Because cascading rules automatically 
trigger other rules, business rules can 
be combined to implement multi-data 
object update processing. 



A change to a single cell in a set of A change to one business rule may 

linked spreadsheets may cause changes affect many business processes which 
20 to cells in many other spreadsheets. are implemented through that rule. 



A further unportant comparison may be drawn between spreadsheet 
ftinctionality and business rule functionality. In a spreadsheet, changing a formula 
is straight-forward. Similarly, because the business rules compiler described 
hereafter automates rules processing and addresses dependencies between business 
25 rules, modifying the business logic is a fairly short and simple procedure. Rules 
are unordered, so the user does not have to be concerned with ordering when 
entering (or, more importantly, altering) rules. 



wo 01/13303 



PCTAJSOO/22318 



Various different types of business rules are defined. The most important 
types for purposes of the present description are derivation rules, constraint rules 
and referential integrity rules. 

Derivation rules define how a colunm's value is computed when a database 
5 update occurs. Derivations can be aggregations of child record values (sums or 
counts-min., max., etc.), replicates (copies) of parent record values, or formulas 
based on values of other columns in the same record. A sum rule derives a parent 
column value by adding values of a specified colunrn in related child data objects. 
A sum may be unconditional ("the total item amount is the sum of the individual 

10 item amounts") or conditional ("the customer balance is the sum of the unpaid 
orders," where unpaid is the condition). A count rule derives a parent column 
value by counting the number of records in related child data objects (e.g., the 
number of unpaid orders). Like sums, counts can be unconditional or conditional. 
Each derivation rule can cause other derivation rules to fire. That is, a change in 

15 dependent data may cause a derivation rule for "A" to fire, and since other 

derivations can be based on "A," a "chain reaction" occurs. This cascading of 
rules enables complex, multi-data object update processing. 

Constraint rules ("constraints") are used to enforce conditions (boolean 
expressions) that refer to multiple columns for data validation. For example, a 

20 constraint may refer to an account balance column, ActBalance, and a credit limit 
column, CreditLimit. Whenever one of these columns is updated, the constraint 
then validates the result (e.g., the update is rejected when the ActBalance > 
CreditLimit). Constraints can refer to the results of derivation rules and can thus 
govern derived columns. 

25 Referential integrity rules preserve relationships between data objects when 

updates occur. A referential integrity rule may prevent parent update if children 
are present, prevent parent delete if children are present, prevent child 
insert/update if parent is not present, etc. Various types of "cascade" referential 
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integrity rules may be specified, including cascade update (update child foreign 
keys on parent update of primary key), cascade delete (delete children on parent 
delete), cascade insert (insert parent if none on child insert/update), and cascade 
nullify (null child foreign keys on parent delete). 

5 Business rules may be specified in various different ways. In an exemplary 

embodiment, a Business Rules Designer provides a graphical user interface to 
define business logic in the form of declarative business rules. Referring to Figure 
3, the Business Rules Designer may consist of several overlapping tab sheets used 
to define different types of business rules, and a Rule Builder tool used for 

10 graphically building expressions. 

In the embodiment of Figure 3, the Columns tab of the Business Rules 
Designer has a read-only grid of all the columns in a selected data object, with 
their column-level rule information. Rules are displayed within the grid but are not 
input directly into the grid. 

15 Referring still to Figure 3, the Derivation tab allows a user to enter rules 

that define how a column's value is derived when update occur. Various options 
may be selected from the derivation-type box. Types of derivations include sums 
and counts, parent replicates, formulas and defaults (described above). For sums 
and counts, two buttons are available, a browser button that invokes die Rules 

20 Builder, described hereafter, and a syntax checker button. 

Referring to Figure 4, the Constraints tab allows the user to define data 
object-level constraints that enforce multiple-column conditions for data validation. 
This tab provides a grid that lists information for all constraints defined for the 
selected data object. The Constramt Name field allows the user to specify a unique 

25 name for a constraint. The Condition field allows the user to enter an expression 
describing the constraint's condition, optionally using the Rule Builder. 

Referring to Figure 5, the Relationships tab provides information about 
parent-child relationships for the selected data object. This tab also allows the user 
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to modify referential integrity rules. A relationships outiine lists the parent and 
child relationships for the selected data object, and lists the primary and foreign 
keys for each relationship. The user selects a relationship from dais outiine to 
modify its rules. A referential integrity frame allows the user to modify the 
system's default referential integrity rules to preserve relationships between data 
objects when updates occur. An Enforce referential integrity checkbox provides 
separate sets of referential integrity rule options buttons for parent updates, parent 
deletes, and child insert/updates. 

Referring to Figure 6, the Events tab allows the user to incorporate custom 
code into system-generated application code. A grid lists a name and description 
for each business rule event defined for a selected data object. Events may be of 
different types, e.g., an in-line trigger code event, a conditional action event, or a 
user-defined modification event. Of particular interest are conditional action 
events. A conditional action event call a specified action (fimction or stored 
procedure) to be executed when a defined condition evaluates to true. A 
Condition/ Action box allows the user to enter an expression to specify the function 
or stored procedure to be executed and any arguments to be passed. A Rule 
Builder tool may be used to complete tiiese fields if desired. 

A Rule Builder screen display is shown in Figure 7. The Rule Builder is 
used to create expressions graphically. The Rule Builder provides lists of columns, 
functions, and keywords, as well as buttons with expression elements. The user 
clicks an item to include it in an expression. The list of columns uses outiine 
controls for explorer-like expansion of column information. The list of functions 
includes built-in RDBMS functions and any custom functions such as stored 
procedures (2 tiered), or Java functions (3 tiered) that have been registered. The 
user, when entering conditional expressions for sum, count, column validation or 
constraint rules, etc., may select from the functions in the list box. The list of 
functions is extensible; i.e., the user may define new functions as methods in Java, 
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for example, and register those methods with an External Object Manager, after 
which they will be listed as functions in the list box for use within die Rules 
Builder. 

The list of keywords includes Inserting, Updating, and ":01d". The :01d 
keyword allows the user to differentiate between a changed column value and its 
value before the transaction that caused the change. 

Although a preferred method of specifying business rules has been 
described, various other methods may also be used, including sunple text input 
usmg a text editor (a ''rules language"), for example. 

Defining business rules is basically the same whedier a declarative 
approach or a procedural approach is followed, and involves identifying business 
functions and the requirements of those functions, then defining one or more rules 
that implement each requirement. The main difference between the two approaches 
is Uiat, in the declarative approach, designing the business logic rule is the 
implementation; i.e., declaring the rules allows the code to be automatically 
unplemented. In the procedural approach, such rules are, by contrast, merely an 
excellent specification for the code to be built by a programmer. 

Business Rules — Compilation 

In an exemplary embodiment, the business rules implementation process 
has two important characteristics. 

First, rules are unordered: the system automatically detects rule 
dependencies and computes an order of execution that is correct and optimal. 
Optimization is repeated when rules are changed, so performance remains high 
over mamtenance changes. In the same manner, ordering analysis assures that rule 
enforcement remains correct (i.e., mdependent data is calculated first). 

Second, rules are transaction-independent: the system automatically 
computes which transactions are affected by a rule and builds logic for those 
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transactions to implement the rule. For example, a rule regarding customer 

balance is automatically reused for many transactions, e.g., insert orders, delete 

orders, pay orders, etc. 

Referring to Figure 9, a simplified block diagram is shown of a business 
5 rules compiler that automatically generates code to implement the foregoing 

business logic rules. Input to the business rules compiler may be in the form of a 

Business Rules Report, an example of which is shown in Appendix A. 

Conceptually, the business rules compiler is divided into four stages, a 

rule/transaction mapping stage, a rule ordering stage, a rule optimization stage, 
10 and a rule targeting (code generation) stage. The operation of each of these stages 

will be described in turn. 

The function of the rule/transaction mapping stage is to determine the 

conditions under which data changes must '*chain" to fire dependent rules. In the 

simplest case, consider a Data Object/Order Item in which the attribute Amount 
15 has a Derivation Rule of Price times Quantity. The rules compiler must generate 

code to recompute Amount if a transaction occurs m which updates are made to 

Price or Quantity. 

Consider a more complicated case where derivation rules reference 

attributes m other Data Objects. For example, the Customer Balance attribute's 
20 derivation depends on the Order's Amount and Paid attributes. As noted above, 

the system must detect transactions that alter an Order's Amount or Paid attribute. 

and recompute the Customer Balance. Moreover, the system must also detect 

transactions that insert Orders (increase the balance) or delete Orders (decrease the 

balance). While such transaction analysis may seem straightforward, it is a 
25 frequent source of error since the number of such cases to be analyzed is very 

large, and because changes to requirements result in subtle side-effects that render 

prior transaction analyses incorrect. 
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The rules ordering stage computes a correct order in which to perform the 
busmess logic operations identified during the rules mapping stage. A dependency 
graph algorithm is used for this purpose. The use of dependency graphs is 
well-known. Given a two-column table of derived and referenced attributes of the 

5 type described, the algorithm essentially looks for atuributes that are referenced but 
are not themselves derived, i.e., attributes that appear on the left side of the table 
with no entries on the right side of the table. The corresponding derivation 
expression is then placed in order and removed wherever found from right side of 
the table, and the process is repeated. In this manner the table is progressively 

10 reduced. 

For example, one derivation expression may be A = X*Y, and another 
derivation expression may be B = 5*A. Assuming for the moment that these are 
die only derivation expressions, then X and Y are referenced but are not 
themselves derived. Therefore, X and Y appear on the left side of the table with 

15 no entries in the right side of the table. "A" is referenced but is derived. Since X 
and Y have no entries on the right side of the table, they are removed from the 
right side of the table. As a consequence, A then has no entries on the right side of 
the table and is therefore removed from the right side of the table and code is 
generated to derive it. This leaves B with no entries (or rather only a constant 

20 entry) on the right side of the table so code is generated to derive it. Any instances 
of B (in this case there are none) are then removed from the right side of the table. 
The foregoing process defines an order in which the derivation expression A = 
X*Y is therefore placed before the derivation expression B = 5*A. The work of 
the ordering stage, in this example, is complete. 

25 In some instances, there may be a mutual dependency, or 6cycle,6 that 

cannot be resolved. A cycle is detected when execution of a code loop performmg 
the foregoing steps does not result in any removals, but the right side of the table 
is still not empty. A cycle is reported as an error to die user. 
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Together, the rules mapping and rules ordering stages identify operations 
and an execution order to achieve correct results in accordance with the rules. The 
optimization stage then computes an efficient implementation of these functionally 
correct operations. More particularly, Base Components (data objects physically 

5 residing on disk) provide insertQ, updateQ and delete() methods which enforce 
Business Rules. This execution is highly optimized for good performance. 

Note that many of the Business Rules stipulate cross-object processing, 
resulting in multi-object transactions. For example, changing an Order Item 
quantity requires the Part on-hand quantities to be adjusted and the Order Amount 

10 to be recalculated. The generated code performs automatic object caching and 
cache checking in recognition of the fact that a given change may require that 
more than one column of a data object be adjusted. When the data object is first 
read to allow the first data column to be adjusted, it is cached. The data object is 
not written back to main storage until later. Therefore, when a subsequent column 

IS is to be adjusted, the column of the cached copy is adjusted. Also, where multiple 
rules span the same relationship, the business rules compiler recognizes this and 
builds logic that enforces all these rules widi a single I/O operation. 

In general, the system buffers updates made during a transaction and 
re-uses these cached data for subsequent processing. Consider, for example, 

20 updates to two items within the same order. The first order update causes the order 
component to be retrieved and updated. Instead of saving the row to the database 
server, it is saved into cache. The second order update may therefore update the 
cached row without retrieving the order. The cached order row is the written to 
disk at the conclusion of Save All processing, when all rows have been processed. 

25 Another optimization involves aggregation. As previously described, the 

customer balance may be defined as the sum of the unpaid orders. Assume that an 
order is changed, e.g., increased from 100 to 120. An inefficient implementation 
of the foregoing rule would be to, whenever an order is changed, re-sum all of the 
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unpaid orders. Instead, child objects generate adjustments to parent aggregate data 
in order to persistently maintain the aggregate data. Hence, when the order amount 
is increased from 100 to 120, 20 is added to the customer balance. 

A further optimization involves rule by-pass. Because the business rules 
S compiler analyzes all dependencies inferred by the rules, it can use this knowledge 
to build code that bypasses processing when underlying dependencies have not 
been affected. For example, altering an order's date requires no adjustment to the 
related customer^Es balance. Similarly, altering an orderiEs date requires no 
re-validation of an existing customer number (i.e., referential integrity). 

10 Various other optimization may be performed. 

At the completion of the optimization stage, the business rules compiler 
will have computed a correct and efficient order in which to enforce the business 
rules. The rule targeting stage then generates actual code to enforce the busmess 
rules. The code generation process may be bener understood by considering what 

15 code needs to be generated for each of various kinds of rules, i.e., derivation 
rules, constraints, and referential integrity rules. 

Recall that derivation rules may be based on formulas entered by the user 
or on aggregates or replicates. In the case of a user formula, the code generated is 
essentially of the form: 

20 IF any-referenced-attribute-changed THEN do {calculate drivation 

formula}. 

Observe now how these rules operate in a typical real world transaction. 
Table 2 depicts the Requirements (bold text) and resultant rules (buUeted pomts) as 
they might have been conceived by a developer and entered into the system. 
25 Imagine now that the order item Quantity is altered by a transaction. The circled 
numbers and arrows represent the rules that fire in response to the change, per the 
IF < reference fields changed > tests for each of the rules types described above. 
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Recall that the order of firing (represented by the arrows) is made correct by the 
Dependency Graph Analysis described above. 

In the case of aggregations, the rules targeting stage generates code to, if a 
"hot" field (i.e., a field referred to in a derivation rule) changed, get the 
5 appropriate related record and add a "delta" to the aggregate, then make the object 
update itself. In the case of the example othe customer balance is the sum of the 
unpaid orders,6 for example, the paid flag and the order amount are "hot." If a 
paid flag is changed, then the customer balance is decreased by the corresponding 
order amount. 

10 In the case of replicates, the rules targeting stage generates code to, if the 

replicate field is changed, copy a field to related fields. In the previous example, 
when an order is marked as paid, then order items belonging to that order may 
also be marked as paid. 

In the case of constraints, the rules targeting stage generates code to check 

15 basic attributes. If a change satisfies a constramt, then the change is allowed. 
Otherwise, the change is not allowed, all partially complete updates are rolled 
back, and a message is returned to the client. Similarly in the case of referential 
integrity rules, the rules targeting stage generates code to check whether a change 
satisfies the rule. If a change satisfies the rule, then the change is allowed. 

20 Otherwise, the change is not allowed, and an error is signalled. 

Consider, for example, the partial E/R diagram of Figure 8 in relation to 
the business function of inserting an order item. A business rule may enforce a 
customer credit limit, i.e.. Customer Balance not > CreditLimit. Evaluation of 
this rules expression may in turn require that the Customer Balance be recomputed 

25 as the sum of impaid Order Totals. A summary of various rules caused to fire by 
inserting an order item in a typical real-world example is given in Table 2. 
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Table2 

Check Credit Limit 

• Customer Balance not > CieditLimit 

• Customer Balance = sum of unpaid Order Totals 




Compute Order Tbtal 

• Order Total = Freight + Amount Items 

• Amount Items = sum (Item Amounts) 

• Item Amount = QtyOrdered * Price 

• Item Price = Part Price at time of order 



Determine wlietlier Reorder required 

• Reorder if OnHand - QtyUnShipped < Reorder Level 

• QtyUnShipped = sum(Item QtyOrdered) where unship] 

• Item.UnShipped is obtained from Order 



As described previously in relation to Figure 2, a three-tiered architecture 
using application servers allows data sources such as legacy (e.g., mamframe) 
appUcations and package solutions (e.g., PeopleSoft or SAP) to be used m 
conjunction with new data to support a custom business process. Chirrent products 
provide basic capabilities to manipulate multiple data sources. Such products, 
however, are unable to mtegrate multiple data sources into a common data model 
together with new data, and to build composite applications usmg declarative 
business rules. This busmess requirement is met using an extensible Data Access 
(XD A) architecture that allows a user to define data objects whose data is not 
retrieved/written by SQL conmiands, but by any API (Application Program 
Interface). For example, a user may define data objects that are based on CICS 
APIs, PeopleSoft APIs, etc. Such data objects can co-exist m a repository 
describing data from multiple data sources, including local SQL data. In this 
manner, the repository mtegrates multiple disparate data sources into a common 
data model. 
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The declarative business rules methodology described heretofore may be 
extended to XDA data objects, allowing a user to define business rules on such 
data objects just as for SQL objects. One aspect of die XDA architecture is 
retrieval and another is update. When a client makes a retrieval request for an 
XDA object, the application server, instead of routing the request as normal to a 
default data manager, calls XDA code identified by the user in the repository 
definition of the Data object. For update, the application components, instead of 
emitting SQL, emit calls to user-supplied XDA code to read/write data. 

To define an XDA data object, the user registers XDA code (e.g., a Java 
class) in the repository and develops the XDA code. The user then uses die 
Busness Rules Designer to designate this XDA Driver by specifying its name as a 
property value of desired Data Objects. Generally speaking, the XDA code is 
required to start a query, retrieve a row, and handle insert/update/delete 
operations. 

It will be appreciated by those of ordinary skill m the art diat the 
invention can be embodied in other specific forms without departing from the spirit 
or essential character thereof. The presentiy disclosed embodiments are therefore 
considered in all respects to be illustrative and not restrictive. The scope of the 
invention is indicated by the appended claims radier tiian the foregoing description, 
and all changes which come within the meaning and range of equivalents diereof 
are intended to be embraced therein. 
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What is claimed is: 

1 . A method of developing a database application, comprising: 
specify business rules describing requirements pertaining to one or 

more business functions; and 

compiling the business rules to automatically generate machine 
instructions for enforcing the business rules. 

2. The method of Claim 1, wherein at least one of the business rules is 
a derivation rule, and specifying comprises forming a rules expression. 

3. The method of Claun 2, wherein the rules expression is formed m 
accordance with a specified rules language syntax. 

4. The method of Claim 2, wherein the rules expression is used in at 
least one of the following: sum/count qualification, formula evaluation, and 
constraint evaluation. 

5. The method of Claim 2, wherem the rules expression is formed 
graphically by selecting at least one of an item from a list and a button labelled 
with a rules expression element. 

6. The method of Claim 1, wherein at least one of the business rules is 
a constraint rule, and specifying comprises identifying multiple columns within the 
database. 

7. The method of Claim 1 , wherein at least one of the business rules is 
a referential integrity rule, and specifying comprises selecting from among 
multiple options a single option within each of multiple categories. 
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8. The method of Claim 1, wherein compiling the business rules 
comprises automatically identifying how changes to a changed field are to be 
propagated to one or more derived fields. 

9. The method of Claim 8, wherein the changes are propagated to 
5 derived fields across multiple data objects. 

10. The method of Claim 9, wherein a derived field is a qualified sum 
or count of a particular field in multiple related data objects. 

1 1 . The method of Claim 9, wherein a derived field is a replicate of a 
particular field in a related data object. 

10 12. The method of Claim 1 1 , wherein the derived field is maintained 

upon subsequent changes to the particular field in the related data object. 

13. The method of Claim 1, wherein compiling the business rules 
comprises computmg an order of execution of multiple processes that produces 
correct results in accordance with the business rules. 

15 14. The method of Claim 13, wherein the multiple processes automate 

multiple inter-dependent rules. 

15. The method of Claim 13, wherein compiling the business rules 
comprises automatically identifying optunizations for efficient execution of the 
multiple processes. 
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16. The method of Claim 1 , wherein compiling the business rules 
comprises automatically generating code for enforcing the business rules, 

17. The method of Claim 1, wherein the database application accesses 
SQL data. 

5 18. The method of Claim 17, wherein the database application accesses 

SQL data and non-SQL data. 

19. The method of Claim 1, wherein die database application accesses 
disparate types of data and enforces the business rules across the disparate types of 
data. 
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ExceededMaxLimit 



Accept When 



Credit Limit MaxCreditLimit or 



PreventDeleteslfO 



Reject When 



(deleting and :oldJsOnHold 1=0) 



PreventOrderifOnHo 



Reject When 



(NumOrderUnpaid > :oldNumOrdersUnpaid 



IT 



Constraint Name IBalanceExceeded 
Condition 



O Accept When 
® Reject When 



ActBalance > CreditLimit 

/*Rules can have cascade dependencies... 

-the CreditLimit is entered by the End User, but., 
•see the Column Derivation rule for ActBalance 

V 



Error Message | Customer balance is exceeding credit limit 
Error Column | CreditLimit 
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Business Rules Designer - CODETABLECREPn' 



Columns | Relationships | Constraints | Events | Properties | 



• Relationships to Child Tables 



:;::-:Ci3StQnner:;[CUST:QMEBS?v 



Relationships to Parent Tables 



f- Referential Integrity 

GZl Enforce Referential Integrity 



f-On Parent Update — 
@ Prevent If Children 
O Update Children 



r-On Parent Delete 

® Prevent If Children 

O Delete Children 

O Null Children Foreign Key 



|-0n Child Insert/Update - 
® Prevent If No Parent 
O Insert Parent If None 
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Rule Builder • Create Validation: [CUSTOMERS] 



^u\e Expression 



+ 






JLiJL^ 




And ll Between 


Like II In || Is || Null || Not 



Columns 



Functions 



Street 
City 
State 
ZIP 

ActBalance 
IsOnHold 
CreditLimit 
CreditCode 
NumOrdersPaid 
NumOrdersUnpaid 
^iMaxcaeaittjmit^v)^^^ 



OK 



Add_Months 
current^Event ♦ 
date 

InCurrentYear 
payAudit 

sendBlgOrderMail 
sendPriceAdjustMail 



Keyword 




FIG..7 



CustNum 










Name 




CustNum 


Street 




OrderNumber 


City 




SalesReplD 


State 




PlacedDate 


ZIP 




OrderPaid 


ActBalance 




Due Date 


IsOnHold 




ShIpDate 


CreditLimit 




Freight 


CreditCode 




Amountltems 


NumOrdersPaid 




OrderTotal 


NumOrdersUnpaid 




ShippedFlag 


MaxCreditUmit 




CurrentYear 


NextOrderNumber 







OrderNum 

PartNum 

QtyOrdered 

Amount 

PartPrice 

ShippedFlag 

Notes 



••PartNum: • . • 
Name 
Make 
Model 
Type 

UriitOfSale 
Price 

QtyOnHand 

QtyUnshipped 

QtyShipped 

QtyReorder 

QtyReceived 

NeedsReorder 

LatestCost 
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